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ABSTRACT 



We present HORNET, a system that enables high-speed end-to-end 
anonymous channels by leveraging next generation network archi- 
tectures. HORNET is designed as a low-latency onion routing sys- 
tem that operates at the network layer thus enabling a wide range 
of applications. Our system uses only symmetric cryptography 
for data forwarding yet requires no per-flow state on intermediate 
nodes. This design enables HORNET nodes to process anonymous 
traffic at over 93 Gb/s. HORNET can also scale as required, adding 
minimal processing overhead per additional anonymous channel. 
We discuss design and implementation details, as well as a perfor- 
mance and security evaluation. 

1. INTRODUCTION 

Recent revelations about global-scale pervasive surveillance pro- 
grams have demonstrated that the privacy of Internet users world- 
wide is at risk. These revelations suggest massive amounts of pri- 
vate data, including web browsing activities, location information, 
and personal communications are being harvested in bulk by do- 
mestic and foreign intelligence agencies. The surveillance-prone 
design of the Internet accompanied by the decreasing cost of data 
storage have enabled mass-surveillance, through indiscriminate data 
collection and storage 1 12, 8 |. 

To protect against these and other surveillance threats, several 
anonymity protocols, tools, and architectures have been proposed. 
Among the most secure schemes for anonymous communications 
are mix networks I28II36II20II21I . which are useful for cases where 
high-latency asynchronous messaging can be tolerated. Onion rout- 
ing networks (most notably Tor [23 1), offer a balance between se- 
curity and performance, enabling low-latency anonymous commu- 
nication suitable for typical Internet activities (e.g., web browsing, 
instant messaging, etc.). Tor is the system of choice for over 2 mil- 
lion daily users jlSl , but its design as an overlay network suffers 
from performance and scalability issues: as more clients use Tor, 
more relays must be added to the network. Additionally, Tor's de- 
sign requires per-connection state to be maintained by intermediate 
nodes, limiting the total number of concurrent anonymous connec- 
tions that can take place simultaneously. 

The scalability and performance limitations of anonymous net- 
works have been partially addressed by building protocols into the 
network layer rather than implementing them as overlays. Among 
these high-performing schemes are LAP |29| and Dovetail |42|, 
which offer network-level low-latency anonymous communication 
on next-generation network architectures. The high performance 
of both schemes, however, results in significantly degraded secu- 
rity guarantees; endpoints can be de-anonymized if the adversary 
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has global data collection abilities, and payload protection relies 
on upper layer protocols which increases complexity. 

In this paper, we present HORNET (High-speed Onion Routing 
at the NETwork layer), a highly-scalable anonymity system that 
leverages next-generation Internet architecture design. HORNET 
offers payload protection by default, and can defend against some 
global observation attacks. HORNET is designed to be highly ef- 
ficient: instead of keeping state at each relay, connection state (in- 
cluding, e.g., onion layer decryption keys) is carried within packet 
headers, allowing intermediate nodes to quickly forward traffic for 
large numbers of clients. 

While this paper proposes and evaluates a concrete ano-nymity 
system, a secondary goal herein is to broadly re-think the design 
of low-latency anonymity systems by envisioning networks where 
anonymous communication is offered as an in-network service to 
all users. For example, what performance trade-offs exist between 
keeping anonymous connection state at relays and carrying state in 
packets? If routers perform anonymity-specific tasks, how can we 
ensure that these operations do not impact the processing of regu- 
lar network traffic, including in adversarial circumstances? And if 
the network architecture should provide some support for anony- 
mous communication, what should that support be? Throughout 
the paper we consider these issues in the design of our own system, 
and provide intuition for the requirements of other network-level 
anonymity systems. 

Specifically, our contributions are the following: 

• We design and implement HORNET, an anonymity system 
that uses source-selected paths and shared keys between end- 
points and routers to support onion routing. Unlike other 
onion routing implementations, HORNET routers do not keep 
per-flow state or perform computationally expensive opera- 
tions for data forwarding, allowing the system to scale as new 
clients are added. 

• We analyze the security of our system, showing that it can 
defend against passive attacks, and certain types of active 
attacks. Our system provides stronger security guarantees 
than existing network-level anonymity systems. 

• We evaluate the performance of our system, showing that 
anonymous data processing speed is comparable to that of 
LAP and Dovetail (up to 93.5 Gb/s on a 120 Gb/s software 
router). Each HORNET node can process traffic for a practi- 
cally unlimited number of sources. 

2. PROBLEM DEFINITION 

We aim to design a network level anonymity system to frustrate 
adversaries with mass surveillance capabilities. Specifically, an ad- 
versary observing traffic traversing our system should be unable to 
link (at large scale) pairs of hosts communicating over the network. 
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This property is known as end-to-end unlinkability |39l . 

We define sender anonymity as a communication scenario where 
unlinkability is guaranteed for the source, but the destination's lo- 
cation is public (e.g., web sites for The Guardian or Der Spiegel). 
We define sender-receiver anonymity as a scenario where the un- 
linkability guarantee is extended to the destination (e.g., a hid- 
den service that wishes to conceal its location). Sender-receiver 
anonymity therefore offers protection for both ends, implying sender 
anonymity. Depending on users' needs, HORNET can support ei- 
ther sender anonymity or sender-receiver anonymity. 

Since our scheme operates at the network layer, network location 
is the only identity feature we aim to conceal. Exposure of network 
location or user identity at upper layers (e.g., through TCP sessions, 
login credentials, or browser cookies) is out of scope for this work. 

2.1 Network Model 

We consider that provisioning anonymous communication be- 
tween end users is a principal task of the network infrastructure. 
The network's anonymity-related infrastructures, primarily routers, 
assist end users in establishing temporary anonymous sessions for 
anonymous data transmission. 

We assume that the network layer is operated by a set of nodes 
(e.g., ASes). Each node cooperates with sources to establish anony- 
mous sessions to the intended destinations, and processes anony- 
mous traffic within the created sessions. We require that routing 
state allows each node to determine only the next hop. In particu- 
lar, the destination is only revealed to the last node and no others. 
This property can be satisfied by IP Segment Routing iTOl . Future 
Internet Architectures (FIAs) like NIRA Ii46|| and SCION f48l, or 
Pathlets (26). 

We assume the underlying network architecture provides a mech- 
anism for a source to obtain a path to a destination. This path is the 
combination of routing state of all nodes between the source and the 
intended destination. Additionally, we assume that the same mech- 
anism allows the source to fetch the public keys and certificates^ of 
on-path nodes. The source retrieves the above information anony- 
mously using one of two methods: I) using unprotected queries 
to retrieve the necessary information to reach a public path lookup 
server and then creating an anonymous session to the server; or 2) 
using any form of Private Information Retrieval (PIR), as was re- 
cently proposed for Tor |35 1. In Section lTTl we briefly sketch how 
to obtain this information anonymously in selected FIAs. While a 
general solution represents an important avenue for future work, it 
remains outside of our present scope. 

We assume that end hosts and on-path nodes have public keys 
accessible and verifiable by all entities. End hosts can retrieve the 
public keys of other end hosts through an out-of-band channel (e.g., 
websites) and verify them following a scheme like HIP [37.1 , in 
which the end hosts can publish hashes of their public keys as their 
service names. Public keys of on-path nodes are managed through 
a public-key infrastructure (PKI). For example, the source node can 
leverage Resource Public Key Infrastructure (RPKI) 1161 to verify 
the public keys of on-path nodes. 

2.2 Threat Model 

We consider an adversary attempting to conduct mass surveil- 
lance. Specifically, the adversary collects and maintains a list of 
"selectors" (e.g., targets' network locations, or higher-level proto- 
col identifiers), which help the adversary trawl intercepted traffic 
and extract parts of it for more expensive targeted analysis | 8|. An 
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anonymity system should provide no way for such an adversary to 
leverage bulk access to communications to select traffic that be- 
longs to the targets. Thus an adversary will have to collect and an- 
alyze all traffic and cannot reliably select traffic specific to targets 
unless it has access to the physical links next to the targets. 

We consider an adversary that is able to compromise a fraction 
of nodes on the path between source and destination. For sender 
anonymity, the adversary can also compromise the destination. For 
sender-receiver anonymity, the adversary can compromise at most 
one of the two end hosts. 

By compromising a node, the adversary learns all keys and set- 
tings, observes all traffic that traverses the compromised node, and 
is able to control how the nodes behave including redirecting traffic, 
fabricating, replaying, and modifying packets. However, like other 
low-latency schemes, we do not solve confirmation attacks based 
on the analysis of flow dynamics |43ll31||38l and active packet tag- 
ging |40|. Resisting such attacks using dynamic link padding 1451 
is no more difficult than in onion routing, although equally expen- 
sive. 

2.3 Desired Properties 

HORNET is designed to achieve the following anonymity and 
security properties: 

1 . Path information integrity and secrecy. An adversary should 
not be able modify a packet header to change path without 
detection. The adversary should not learn forwarding infor- 
mation of uncompromised nodes, node's positions, or the to- 
tal number of hops on a path. 

2. No cross-link identification. An adversary that can eaves- 
drop on multiple links in the network cannot correlate two or 
more packets on those links by observing the bit patterns in 
the packet headers or pay loads. 

3. Session unlinkability. An adversary cannot link packets 
from different sessions, even between the same set of sources 
and destinations. 

4. Payload secrecy and end-to-end integrity. Without com- 
promising end hosts, an adversary cannot learn any informa- 
tion from the data payload except for its length and timing 
among sequences of packets. 

3. HORNET OVERVIEW 

The basic design objectives for HORNET are scalability and effi- 
ciency. To enable Internet-scale anonymous communication, HOR- 
NET intermediate nodes must avoid keeping per-session state (e.g., 
cryptographic keys and routing information). Instead, session state 
is offloaded to end hosts, who then embed this state into packets 
such that each intermediate node can extract its own state as part of 
the packet forwarding process. 

Offloading the per-session state presents two challenges. First, 
nodes need to prevent their offloaded state from leaking informa- 
tion (e.g., the session's cryptographic keys). To address this, each 
HORNET node maintains a local secret to encrypt the exported 
per-session state. We call this encrypted state a Forwarding Seg- 
ment (FS). The FS allows its creating node to dynamically retrieve 
the embedded information (i.e., next hop, shared key, session expi- 
ration time), while hiding this information from unauthorized third 
parties. 

The second challenge in offloading the per-session state is to 
combine this state (i.e., the FSes) in a packet in such a way that each 
node is able to retrieve its own FS, but no information is leaked 
about the network location of the end hosts, the path length, or a 
specific node's position on the path. Learning any of this informa- 
tion could assist in de-anonymization attacks (see Section l53t . To 
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address this challenge, the source constructs an anonymous header 
(AHDR) by combining multiple FSes, and prepends this header to 
each packet in the session. An AHDR grants each node on the 
path access to the FS it created, without divulging any informa- 
tion about the path except for a node's previous and next nodes 
(see Section l4Xn ). 

For efficient packet processing, each HORNET node performs 
one Diffie-Hellman (DH) key exchange operation once per session 
during setup. For all data packets within the session, HORNET 
nodes use only symmetric cryptography to retrieve their state, pro- 
cess the AHDR and onion-decrypt (or encrypt) the payload. To re- 
duce setup delay, HORNET uses only two setup packets within a 
single round trip between the source and the destination. Therefore, 
session setup only incurs 0{n) propagation delay in comparison to 
O(n^) by the iterative method used in Tor (where n is the number 
of anonymity nodes traversed on the path). While for Tor the de- 
fault value of n is 3, for HORNET n might be as large as 14 (and 
4. 1 in the average case (7)), which emphasizes the need to optimize 
setup propagation delay in our protocol. 

3.1 Sender Anonymity 

Anonymous sessions between a source and destination require 
the source to establish state between itself and every node on the 
path. The state will be carried in subsequent data packets, enabling 
intermediate nodes to retrieve their corresponding state and forward 
the packet to the next hop. We now describe how the state is col- 
lected without compromising the sender's anonymity, and how this 
state is used to forward data packets. 

Setup Phase. To establish an anonymous session between a source 
S and a public destination D, S uses a single round of Sphinx 1 21 1, 
a provably secure onion routing protocol (an overview of Sphinx is 
given in Section |4.3.1| l. This round consists of two Sphinx packets 
(one for the forward path and one for the backward path) each of 
which will anonymously establish shared symmetric keys between 
S and every node on that path. For HORNET, we extend the Sphinx 
protocol to additionally anonymously collect the forwarding seg- 
ments (FSes) for each node. Our modified Sphinx protocol protects 
the secrecy and integrity of these FSes, and does not reveal topol- 
ogy information to any node on the path. We note that using Sphinx 
alone for data forwarding would result in low throughput due to 
prohibitively expensive per-hop asymmetric cryptographic opera- 
tions. Therefore, we use Sphinx only for session setup packets, 
which are amortized over the subsequent data transmission pack- 
ets. We explain the details of the setup phase in Section l431 
Data Transmission Pliase. Having collected the FSes, the source 
is now able to construct a forward AHDR and a backward AHDR 
for the forward and backward paths, respectively. AHDRs carry the 
FSes which contain all state necessary for nodes to process and 
forward packets to the next hop. When sending a data packet, the 
source onion-encrypts the data payload using the session's shared 
symmetric keys, and prepends the AHDR. Each node then retrieves 
its FS from the AHDR, onion-decrypts the packet and forwards it to 
the next hop, until it reaches the destination. The destination uses 
the backward AHDR (received in the first data packeQ) to send data 
back to S, with the only difference being that the payload is en- 
crypted (rather than decrypted) at each hop. We present the details 
of the data transmission phase in Section l4!4l 

3.2 Sender- Receiver Anonymity 

Sender-receiver anonymity, where neither S nor D know each 
other's location (e.g., a hidden service), presents a new challenge: 

^If the first packet is lost the source can simply resends the back- 
ward AHDR using a new data packet (see Section l4!4l . 



since S does not know D's location (and vice versa), S cannot 
retrieve a path to D, precluding the establishment of state between 
S and nodes on the path to D as described in Section [3TT] 

A common approach to this problem (as used by Tor, LAP, and 
Dovetail) is for the destination to advertise a path (or similar) back 
to itself through a known, public rendezvous point (RP). Sources 
establish anonymous sessions to the RP, who in turn forwards traffic 
to the destination while keeping S and D's location hidden from 
each other. This solution would also work for HORNET. However, 
it requires the RP to maintain per-session state between sources and 
destinations, which increases complexity, bounds the number of 
receivers, and introduces a state exhaustion denial of service attack 
vector. 

Nested a-headers. Our proposal for sender-receiver anony-mity 
requires no state to be kept at the RP by nesting the AHDRs from 
the source to the rendezvous and from the rendezvous to the desti- 
nation. Briefly, to establish a HORNET session between S and D 
keeping both parties hidden from each other, D selects a public ren- 
dezvous point R and completes a HORNET session setup between 
D and R. D publishes AHDRfl_>£) to a public directory. Note that 
this AHDR leaks no information about D's location and can only be 
used to send data to D through R within a specific time window. 

When S wants to send traffic to D, S retrieves (from a public 
directory) AHDRfl_>£). S then establishes a HORNET session be- 
tween S and R and constructs a nested AHDR with AHDR/j_>£) 
inside AHDR^^/j. S includes AHDR ji^g in the data payload to 
D, allowing D to create a return path to S. 

One of the advantages of our scheme is that any node on the net- 
work can serve as a rendezvous point. In fact, multiple points can 
be selected and advertised, allowing the source to pick the RP clos- 
est to it. Moreover, once a HORNET session has been established, 
S and D can negotiate a better (closer) RP (e.g., using private set 
intersection 1 25 1). A disadvantage of the nested AHDR technique is 
that it doubles the size of the header. 

For space reasons, the formal protocol details and evaluation sec- 
tions focus on sender anonymity only. Details of sender-receiver 
anonymity can be found in the full paper (5). 

3.3 Packet Structure 

HORNET uses two types of packets: setup packets and data 
packets (see Figure[T](. Both types of packets begin with a common 
header which describes the packet type, the length of the longest 
path that the session supports, and a type-specific field. For ses- 
sion setup packets, the type-specific field contains a value EXP 
which indicates the intended expiration time of the session. For 
data packets, the specific value is a random nonce generated by the 
sender used by intermediate nodes to process the data packet. 

Session setup packets include a nested Sphinx packet and an FS 
payload. Data packets carry an AHDR and an onion-encrypted data 
payload. We explain each field in detail in Section|4] 

4. FORMAL PROTOCOL DESCRIPTION 

We now describe the details of our protocol, focusing on sender 
anonymity. We first list the information required by the source to 
start an anonymous communication (Section|4j2l(, and then present 
the specification of the setup phase (Section [4. 3t and of the data 
transmission phase (Section r4.4b . 

4.1 Notation 

Let k be the security parameter used in the protocol. For evalua- 
tion purposes we consider k = 128. Q isa prime order cyclic group 
of order q (q ^ 2^^), which satisfies the Decisional Diffie-Hellman 
Assumption. Q* is the set of non-identity elements in Q and <? is a 
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HORNET Session Setup Packet 



HORNET Data Packet 



type hops 



EXP 



Sphinx Header 



Sphinx Payload 



FS Payload 



type hops nonce 



AHDR 



Data Payload 



Figure 1: HORNET packet formats. 

generator of Q. 

Let r be the maximum length of a path, i.e., the maximum num- 
ber of nodes on a path, including the destination. We denote the 
length of an FS as Ipg and the size of an AHDR block, containing 
an FS and a MAC of size k, as c = Ipg + k. 

HORNET uses the following cryptographic primitives: 

• MAC : {0, 1}'= X {0, 1}* ^ {0, 1}'=: Message Authentication Code 
(MAC) function. 

• PRGO, PRGl : {0, l}'^ ^ {0, l}'^(c+'=); PRG2 : {0, 1}''' ^ {0, 1}'''=: 
Three cryptographic pseudo-random generators. 

• PRP : {0, 1}'' X {0, 1}" ^ {0, 1}'': A pseudo-random permuta- 
tion, implementable as a block cipher. The value of a will be 
clear from the context. 

• ENC : {0,1}'= X {0,1}'= X {0,1}™'= ^ {0,1}™'=: Encryption 
function, with the second parameter being the Initialization Vec- 
tor (IV) (e.g.. Stream cipher in counter mode), m is a variable 
integer parameter. 

• DEC : {0,1}'= X {0,1}'= X {0,1}™'= ^ {0,1}™'=: Decryption 
function to reverse ENC. 

• hop : t/* — 7- {0, 1}'=: a family of hash functions used to key op, 
with op e {MAC, PRGO, PRGl, PRP, ENC, DEC}. 

We denote by RAND(Z) a function that generates a new uniformly 
random string of length /. 

Furthermore, we define the notation for bit strings. O' stands for 
a string of zeros of length I. \x\ is the length of the bit string x. 
x^g_ represents a substring of x from bit a to bit b, with sub- 
index a starting from 0; x^^^ g^^jj indicates the substring of x from 
bit s till the end. e is the empty string, a; || y is the concatenation of 
string X and string y. 

In the following protocol description, we consider a source S 
communicating with a destination D using forward path travers- 
ing njj , n| , . . . , n^y _ J and backward path p'' traversing njj , n j , . . . , n^'^ _ 

with if < r, where and are the nodes closest to the 

source. Without loss of generality, we let the last node on the for- 
ward path njj:_^ = D and refer to the destination by these two 
notations interchangeably. In general we use dir e {f,b} as super- 
scripts to distinguish between notation referring to the forward and 
backward path, respectively. Finally, to avoid redundancy, we use 
{symf'^^} to denote {symf^^\0 <i< — 1}, where sym can 
be any symbol. 

4.2 Initialization 

Suppose that a source 5* wishes to establish an anonymous ses- 
sion with a public destination D. First, S anonymously obtains 
(from the underlying network) paths in both directions: a forward 



j^dtr (jgjjotes the routing information needed by the node n*'' to 
forward a packet. 5* also anonymously retrieves and verifies a set of 
public keys g "i^^ for the node nf^^ on path p'^^^ (see Section |2Tt . 
Note that g^'^ is also included in the above set (as = D). 

Finally, S generates a random DH key pair for the session: xg 
and g^^ . The per-session public key g^^ is used by the source to 
create shared symmetric keys with nodes on the paths later in the 

setup phase. 5* locally stores |(j:5,i7^^) , jij "i*"^ | ,p'^'^|, and 
uses these values for the setup phase. 

4.3 Setup Phase 

As discussed in Section |3] in the setup phase, HORNET uses 
two Sphinx packets, which we denote by PO and P0, to traverse 
all nodes on both forward and backward paths and establish per- 
session state with every intermediate node, without revealing S's 
network location. For S to collect the generated per-session state 
from each node, both Sphinx packets contain an empty FS payload 
into which each intermediate node can insert its FS, but is not able 
to learn anything about, or modify, previously inserted FSes. 

4.3.1 Sphinx Overview 

Sphinx 1211 is a provably-secure onion routing protocol. Each 
Sphinx packet allows a source node to establish a set of symmet- 
ric keys, one for each node on the path through which packets are 
routed. These keys enable each node to check the header's in- 
tegrity, onion-decrypt the data payload, and retrieve the informa- 
tion to route the packet. Processing Sphinx packets involves ex- 
pensive asymmetric cryptographic operations, thus Sphinx alone is 
not suitable to support high speed anonymous communication. 

Sphinx Pacltets. A Sphinx packet is composed of a Sphinx header 
SHDR and a Sphinx payload SP. The SHDR contains a group ele- 



path p-f = {Rq , R-^ , ■ ■ • , Rjf _ J } and a backward path - 
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ment yi that is re-randomized at each hop. Each yi is used 
as S's ephemeral public key in a DH key exchange with node n^*"". 
From this DH exchange node n^*'' derives a shared symmetric key 
s^diT, which it uses to process the rest of the SHDR and mutate 

the yi"^^^. The rest of the SHDR is an onion-encrypted data struc- 
ture, with each layer containing the routing information to decide 
the next node to forward the packet and a per-hop MAC to pro- 
tect the header's integrity. The Sphinx payload SP allows end hosts 
to send confidential content to each other. Each intermediate node 
processes SP by using a pseudo-random permutation. 

Sphinx Core Functions. We abstract the Sphinx protocol into the 
following six functions: 

• GEN_SPHX_HDR. The source nodes uses this function to gen- 
erate two Sphinx headers, SHDR-^ and SHDR*", for the forward 
and backward path, respectively. It also outputs a series of DH 

' public-private key pairs {{xi'^^^ ,yi'^^^)} (ephemeral keys of the 
source), and the symmetric keys {s^dir}, each established with 

X dir 

the corresponding node's public key g . 

• GEN_SPHX_PL_SEND. The function allows the source to gener- 
ate an onion-encrypted payload SP-'^ encapsulating confidential 
data to send to the destination. 

• UNWRAP_SPHX_PL_SEND. The function removes the last en- 
cryption layer added by GEN_SPHX_PL_SEND, and allows the 
destination to decrypt the SP-^. 

• GEN_SPHX_PL_RECV. The function enables the destination to 
cryptographically wrap a data payload into SP** before sending it 
to the source. 

• UNWRAP_SPHX_PL_RECV. The function allows the source to 
, i?j^[,rep})ver the plaintext of the payload that the destination sent. 
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• PROC_SPHX_PKT. Intermediate nodes use this function to pro- 
cess a Sphinx packet, and establish symmetric keys shared with 
the source. The function takes as inputs the packet (SHDR,SP), 
and the node's DH public key g "i . The function outputs the 
processed Sphinx packet (shdr',Sp') and the established sym- 
metric key Sj^dir . 

4.3.2 Forwarding Segment 

We extend Sphinx to allow each node to create an FS and add it 
to the FS payload. An FS contains a node's per-session state, which 
consists of a secret key s shared with the source, a routing segment 
R, and the session's expiration time EXP. To protect these contents, 
the FS is encrypted with a PRP keyed by a secret value SV known 
only by the node that creates the FS. A node seals and unseals its 
state using two opposite functions: FS_CREATE and FS_OPEN. We 
introduce only the form of FS_CREATE as follows: 

F5 = PRP(/ipRp(5'y);{s||i?||EXP}) (1) 

4.3.3 FS Payload 

At the end of each HORNET setup packet is a data structure 
we call FS payload (see Figure [T). The FS payload is an onion- 
encrypted construction that allows intermediate nodes to add their 
FSes as onion-layers. 

Processing the FS payload leaks no information about the path's 
length or about an intermediate node's position on the path. All 
FS payloads are padded to a fixed length, which is kept constant 
by dropping the right number of trailing bits of the FS payload 
before an FS is added to the front. Moreover, new FSes are always 
added to the beginning of the FS payload, eliminating the need for 
intermediate nodes to know their positions in order to process FS 
payloads. 

An FS payload also provides both secrecy and integrity for the 
FSes it contains. Each node re-encrypts the FS payload after in- 
serting a new FS and computes a MAC over the resulting structure. 
Only the source, with symmetric keys shared with each node on a 
path, can retrieve all the FSes from the FS payload and verify their 
integrity. 

Functions. There are three core functions for the FS payload: 
INIT_FS_PAYLOAD, ADD_FS, and RETRIEVE_FSES. 

INIT_FS_PAYLOAD. A node initializes a FS payload by using a 
pseudo-random generator keyed with a symmetric key s to gener- 
ates rd random bits: 

PFS = PRGl(/ipRGl(s))[,,..,d-l] (2) 
where d is the size of a basic block of the FS payload (cf. Line|2]in 
Algorithm 

ADD_FS. Each intermediate node uses ADD_FS to insert its FS 
and other meta-data MD into the payload, as shown in Algorithm[T] 
First, the trailing d bits of the current FS payload, which are padding 
bits containing no information about previously added FSes, are 
dropped, and then the FS and MD are prepended to the shortened 
FS payload. The result is encrypted using a stream cipher (LineO 
and MACed (LineO. Note that no node-position information is re- 
quired in ADD_FS, and verifying that the length of the FS payload 
remains unchanged is straight-forward. 

RETRIEVE_FSES. The source uses this function to recover all 
FSes {FSi} and MDs {MDj} inserted into an FS payload Pps- 
RETRIEVE_FSES Starts by recomputing the discarded trailing bits 
(Line|4ll and obtaining a complete payload Pfuii- Afterwards, the 
source retrieves the FSes and MDs from PfuU in the reverse order 
in which they were added by ADD_FS (see lineslTjandllOt. 

4.3.4 Setup Phase Protocol Description 



Algorithm 1 Adding FS into FS payload. 

1 : procedure add_fs 

Input: s, FS, MD, Pi„ 

Output: Pout 
2: |FSi + |MD| + fc 

<- ^FS \\ MD II Pin[d..{r-\)d]\ 
.end\ 

i Ptmp) 

5: Pout <- a II Pfmp 
6: end procedure 



Algorithm 2 Retrieve FSes from FS payload 
1: procedure RETRIEVE_FSES 
Input: Pps, s, {sj} 
Output: {FSi}, MDi 
2: d-(^lps + \MD\ + k 
3: Pinit init_fs_payload(s) 

4: Pinitl{r-l)d..rd-l\ 

© PRG0{hpRC0{so))[ir-l+l)d..end] II O'^ 
®PRG0(ftpRG0(si))[(r-m)d..end] II 0^'* 

® PRG0(ftpRG0(Si-2))[(r-l)d..e«d] II 0('-')'^ 

5: PfuU = Pps II ^ 

6: fori^(/-l),...,Odo 

7: check Pf^up„k-i] = 

MAC{hMAc{Si);Pfull[k..rd-l]) 

8: Pfuii ^ PfuU ®(PRGO(/ipRGo(s»))||0('+')'') 

^' ^^i^ ^f-u.U[k..k+lFs-T.] 

10: MD,^P/„„[^^;^^^_,j 

11: 

12: PfuU ^ Pfull[d..end\ 

13: end for 
14: end procedure 



Source Processing. With the input 

the source node S bootstraps a session setup in 5 steps: 

1. S selects the intended expiration time EXP for the session and 
specifies it in the common header CHDR. 

2. 5* generates the send and the reply Sphinx headers by: 

{shdr-'^jShdr''} = gen_sphx_hdr(J,chdr) (3) 
The common header CHDR (see Figure[T) is passed to the func- 
tion to extend the per-hop integrity protection of Sphinx over 
it. GEN_SPHX_HDR also produces a series of keys: symmetric 
keys shared with each node on both paths {s^dir}, and the DH 

key pairs {{xf'',yf'')}. 

3. In order to enable the destination D to reply, S places the reply 
Sphinx header SHDr'' into the Sphinx payload: 

sp = gen_sphx_pl_send({s^/ }, shdr'') (4) 

4. 5* creates an initial FS payload Pps = INIT_FS_PAYLOAD(a::5). 

5. S composes PO = {chdr || SHDR-'' || SP || Pi^s} and sends it to 
the first node on the forward path Uq . 

Intermediate Node Processmg. An intermediate node receiv- 
ing a packet PO = {CHDR || SHDR-'' || SP || Pps} processes it as 
follows: 

1. nj first processes SHDR-'^ and SP in PO according to the Sphinx 
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protocol (using PROC_SPHX_PKT). As a result obtains the 1. S recovers the FS payload for the forward path Pps^ from sp'' 
processed header and payload (SHDR-^', SP') as well as the rout- 



PpS^ = UNWRAP_SPHX_PL_RECV({S^},SP'') 



(10) 



ing information , S's DH public key y/, and the established 
symmetric key s^/ shared with S. During this processing the 

integrity of the CHDR is verified. 

2. obtains EXP from CHDR and checks that EXP is not expired. 

f f 
also verifies that R - is valid. 

3. To provide forward secrecy, the shared key s^/ is not used for 

the data transmission phase, since s^/ depends on n^'s long- 

term DH key. Instead, generates an ephemeral DH key pair 
{x' f,y' f) and derives by 

s{ = {y{f'"' (5) 
f 

This is the symmetric key that is included in n - 's FS and used 
during the data transmission phase. 

f f 

4. generates its FS FS^^ by using its local symmetric key SVi 

f f 

to encrypt s - , R - , and EXP: 

FS{ = FS_CREATE(S'V^i,{sf || R{ || EXP}) (6) 

5. n{ adds its FS{ and MD = y' f into the FS payload Pps- 

Pfs' = ADD_FS{s^^f,FS{,y'^j,PFs) 0) 
Adding y' f as the meta-data into the FS payload allows S to 

later retrieve y' f and derive the symmetric key shared with 
n'^ for the session. The MAC computed using s^/ shared be- 
tween S and nj (Line|5]in Algorithm[TJ allows S to authenticate 
the DH public key y' f . 

6. Finally node assembles the processed packet PO = {CHDR | 
SHDR-^' II SP' II Pps'} ^nd routes it to the next node according 
to the routing information i?^ . 

Destination Processing. As the last node on the forward path, D 
processes PO in the same way as the previous nodes: it processes 
the Sphinx packet in PO and derives a symmetric key sjj shared 
with S; it generates a new DH key pair {x'jj,y'jj) and derives a 
second shared key s^; it encrypts per-session state including s'^ 
into FSu and inserts FSjj into the FS payload. 

After these operations, however, D moves on to create the sec- 
ond setup P© as follows: 

1. D retrieves the Sphinx reply header using the symmetric key 
SD- 

(8) 



shdr" = UNWRAP_SPHX_PL_SEND(.So,SP) 
2. D places the FS payload Ppg of PO into the Sphinx payload 



SP" of P© (this will allow S to get the FSes {FS{ }) 
SP*" = GEN_SPHX_PL_RECV(s£), Pi?5) 



Note that since D has no knowledge about the keys {s{} except 
for sj), D learns nothing about the other FSes in the FS payload. 

3. D creates a new FS payload Pps'' = INIT_FS_PAYLOAD(s£)) 
to collect the FSes along the backward path. 

4. D composes P© = {CHDR || SHDr'' || Sp'' || Pps''} and sends it 
to the first node on the backward path, tiq. 

The nodes on the backward path process P© in the exact same 
way nodes on the forward path processed PO. Finally P© reaches 
the source S with FSes {FS'^J added to the FS payload. 

Post-setup Processing. Once S receives P© it extracts all FSes, 
i.e., {FS{ } and {FS'^}, as follows: 



(9) 



2. S retrieves the FSes for the nodes on the forward path {FSj}: 

{FS{ } = RETRIEVE_FSES({sf },PfS-^) (H) 

3. S directly extracts from Ppg^ the FSes for the nodes on the 
backward path {FS^}: 

{FS",^} = RETRIEVE_FSES({4}, Pfs'') (12) 

With the FSes for all nodes on both paths, {FS{} and {FS'l}, 
S is ready to start the data transmission phase. 

4.4 Data Transmission Phase 

Each HORNET data packet contains an anonymous header AHDR 
and an onion-encrypted payload O as shown in Figure[T] Figure[2] 
demonstrates the details of an AHDR. The AHDR allows each inter- 
mediate node along the path to retrieve its per-session state in the 
form of an FS and process the onion-encrypted data payload. All 
processing of data packets in HORNET only involves symmetric- 
key cryptography, therefore supporting fast packet processing. 
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Figure 2: Format of a HORNET anonymous lieader with de- 
tails of a forwarding segment (FS). 

At the beginning of the data transmission phase, S creates two 
AHDRs, one for the forward path (AHDR-^) and one for the back- 
ward path (AHDR*"), by using FSes collected during the setup phase. 
AHDR-^ enables 5* to send data payloads to D. To enable D to trans- 
mit data payloads back, 5* sends AHDR** as payload in the first data 
packet. If this packet is lost, the source would notice from the fact 
that no reply is seen from the destination. If this happens the source 
simply resends the backward AHDR using a new data packet. 

4.4. 1 Anonymous Header 

Like an FS payload, an AHDR is an onion-encrypted data struc- 
ture that contains FSes. It also offers similar guarantees, i.e., se- 
crecy and integrity, for the individual FSes it contains, for their 
number and for their order. Its functionalities, on the other hand, 
are the inverse: while the FS payload allows the source to collect 
the FSes added by intermediate nodes, the AHDR enables the source 
to re-distribute the FSes back to the nodes for each transmitted data 
packet. 

Functions. The life cycle of AHDRs involves two functions: GET_FS 
and CREATE_AHDR. GET_FS allows each intermediate node to re- 
trieve its FS from the input AHDR and compute the AHDR for the 
next hop (see Algorithm [Sj- CREATE_AHDR enables S to create 
two AHDRs, AHDR-^ and AHDR** (see Algorithm lU. 

4.4.2 Onion Payload 

HORNET data payloads are protected by onion encryption. To 
send a data payload to the destination, the source adds a sequence 
of encryption layers on top of the data payload, one for each node 
on the forward path (including the destination). As the packet is 
forwarded, each node removes one layer of encryption, until the 
destination removes the last layer and obtains the original plaintext. 
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Algorithm 3 Obtain FS from AHDR 
1 : procedure get_fs 
Input: SV, AHDR 
Output: FS, AHDR 
2: {FS II 7 II /3} ^ AHDR 
3: s^FS_OPEN(FS',S'y)[o..fc] 
4: check7= MAC(/iMAc(s);;5||0'=) 
5: P' ^ {/? II 0=} ® PRG2(/ipRG2(s))[o...rc] 
6: AHDR ^ /?' 
7: end procedure 



Algorithm 4 Anonymous header construction 
1 : procedure create_ahdr 
Input: {s,}, {FS^} 
Output: {FSo,Jo,M 
2: 00 e 

3: for i ^ 1, • ■ • ,Z — 1 do 

4: <^,^(0,_i||O=) 

®|PRG2(/lpRG2(Si_i))[(r_i)c..rc]} 

5: end for 

6: A^{RAND(c(r-O)||0i-i} 
7: fori^(Z-l),...,Odo 

8: Pi ^ {FS^+l \\'y^+l II ft+l [o..c(r-l)-l]} 

®PRG2(/ipRG2(s,)) 
9: 7,^MAC(/iMAc(s»);F5,||ft) 
10: end for 
1 1 : end procedure 



To send a data payload back to the source, the destination adds 
only one layer of encryption with its symmetric key shared with 
the source. As the packet is forwarded, each node on the backward 
path re-encrypts the payload until it reaches the source. With all 
the symmetric keys shared with nodes on the backward path, the 
source is capable of removing all encryption layers, thus obtaining 
the original data payload sent by the destination. 

Functions. Processing onion payloads requires two functions: ADD 
and REMOVE_LAYER. 

ADD_LAYER. The function's full form is: 

{0',/V'} = add_layer(s,71/,0) (13) 
Given a symmetric key s, an initial vector IV, and an input onion 
payload O, ADD_LAYER performs two tasks. First, ADD_LAYER 
encrypts O with s and IV: 

O' = ENC{hENds);IV;0) (14) 
Then, ADD_LAYER mutates the IV for next node: 

71^' = PRP(/ipRp;J'V') (15) 
REMOVE_LAYER. The function is the inverse of ADD_LAYER. 
Without going into details, we only list its full form below: 

{0',7y'} =remove_layer(s,71/,0) (16) 

4.4.3 Initializing Data Transmission 

To start the data transmission session, S generates AHDR-'^ and 
AHDR^ as follows: 

AHDR-'' = CREATE_AHDR({s{},{i^5'/}) (17) 

AHDr'' = CREATE_AHDR({s,^},{i^S'f}) (18) 
S then sends AHDR^ to D as payload of the first data packet (which 
uses AHDR-'^), as specified in the following section. 

4.4.4 Data Transmission Protocol Description 
Source Processing. With the forward ahdr (ahdr-^ ), the source 



S can send a data payload P with the following steps: 

1. 5* ensures that the session is not expired by checking that the 
current time tcurr < EXP. 

2. S creates an initial vector IV. With {s^ }, sjj, and IV, S onion 
encrypts the data payload P. 

{Oif ,IVij} = ADD_LAYER{SD,IV,P) (19) 
{0^,IVi} = ADD_LAYER{sD,IV+uOi+i) i ^ (1^ - 1)..0 

(20) 

3. S places IVo in the common header CHDR. 

4. S sends out the resulting data packet {CHDR, AHDR-'' , Oq}. 

Processing by Intermediate Nodes. Each intermediate node 

on the forward path processes a received data packet {CHDR, AHDR-'^ , O} 

with its local secret key SV^ as follows: 

1. retrieves its FS FS( from AHDR-^ : 

{FS{, AHDR^'} = GET_FS(S'1//,AHDR-'') (21) 

f f 

2. extracts its per-session state, i.e., the symmetric key shared 

with 5", the routing information , and the session's expiration 
time EXP, by decrypting FS with SV/ (cf. with Equation[T]l: 

{sf ,7i/,EXP} = PRP-\hp^p{SV/);FS( ) (22) 

3. checks the session is not expired by verifying that the current 
time tcurr < EXP. 

4. obtains IV from CHDR and removes one layer of encryption 
from the data payload: 

{0',IV'} = remove_layer{s{ ,IV,0) (23) 

5. n{ updates the IV field in CHDR with IV'. 

6. n{ sends the resulting packet {CHDR^AHDR-'^'jO'} to the next 
node according to pj. 

The above procedures show that the intermediate node process- 
ing requires only symmetric-cryptography operations. 
Destination Processing. D processes incoming data packets as 
the intermediate nodes. Additionally, for the first data packet D 
retrieves AHDR*" from the payload, and stores the {s£3,i?Q, AHDR*"} 
locally so that D can retrieve AHDr'' when it wishes to send packets 
LAYit»ck to 5". 

Processing for the Backward Path. Sending and processing a 
HORNET packet along the backward path is the same as that for 
the forward path, with the exception of processing involving the 
data payload. Because D does not possess the symmetric keys 
that each node on the backward path shares with S, D cannot 
onion-encrypt its payload. Accordingly, intermediate nodes use 
ADD_LAYER instead of REMOVE_LAYER to process the data pay- 
load, and the source node recovers the data by REMOVE_LAYER. 

4.5 Nested Anonymous Header Construction 

As discussed in Section [J!2l the main difference of the protocols 
between sender anonymity and sender-receiver anonymity is that 
the latter requires nested AHDRs. We present in detail the process 
of composing an AHDR with a nested AHDR in Algorithm|5] 

Constructing a new AHDR based on a nested AHDR A has es- 
sentially the same procedures as constructing a normal AHDR from 
ASes, except for the initialization process and the size of the re- 
sulted AHDR. For the AHDR initialization in Line [To] in Algo- 
rithmic] the nested AHDR A is perpended to the random bits gener- 
ated. Thus, when the last node n^"" (RP) decrypts the AHDR, A is 
revealed to the node. For the size of the resulted AHDR, instead of r 
for a normal AHDR, the length of the generated AHDR with a nested 
AHDR is 2r, doubling the bandwidth cost incurred by the protocol 
headers. 
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Algorithm 5 Creating an AHDR with a nested AHDR. 
1: procedure create_padding_string_nested 
Input: {sj}, r 
Output: (jfl-l 
2: 00 <- e 
3: for 0 < i < Z do 
4: 0i^(<^i_i||O=)e 

5: |PRGO(/lpRGo(Si-l))[(2r-i)c..2rc]} 

6: end for 
7: end procedure 

8: procedure create_anonymous_header_nested 
Input: {sj, {FS^}, A 
Output: (F5(),7o,A)) 
9: <— CREATE_PADDING_STRING_NESTED({si}) 

10: l3i_i^{{A\\RAND{c{r-l))} 

ePRGO(ftpRGo(Si-l))[()..c(2r-;)-l]} ll-i^i-i 
11: 7,_i ^ MAC(ftMAc(si-l);^'5i-l II A-l) 
12: fori^(Z-2),...,0do 

13: Pi ^ \^FSi+i ||7i+i !|ft+i[o..c(2r-i)-i]} 

® PRGO(/lpRGo(si))[{)..c(2r-;)-l] 

14: 7,^MAC(/iMAc(s»);i^5',||/30 
15: end for 
16: end procedure 



5. SECURITY ANALYSIS 

In this section, we first presents formal proofs showing that HOR- 
NET satisfies the correctness, security, and integrity properties de- 
fined by Camenisch and Lysyanskaya |17|. Then, we describes 
how HORNET defends against well-known de-anonymization at- 
tacks, where an adversary actively or passively attempts to reveal 
the sender's (and/or the receiver's) network location. We also present 
defenses against denial of service attacks. 

5.1 Formal Proof of Security for HORNET Data 
Transmission Phase 

We prove HORNET'S data transmission phase realizes ideal onion 
routing functionalities in the Universal Composability (UC) frame- 
work 1 18 |. Conceptually, with an ideal onion routing protocol, ad- 
versaries have no access to the routing information or the message 
within packets except for opaque identifiers that vary across links. 

As demonstrated by Camenisch and Lysyanskaya 1 17|, to prove 
that a protocol conforms to an ideal onion routing model, it is suf- 
ficient to show that the protocol provides four properties: correct- 
ness, integrity, wrap-resistance, and iecMn'r>'0 

5.1.1 Correctness 

Proving the correctness property requires that HORNET proto- 
col functions correctly in the absence of adversaries. A scrutiny of 
protocol description in Section|4]should suffice. 

5.1.2 Integrity 

To prove the integrity property, we need to prove that an adver- 
sary cannot forge a message that can traverse more than A'^ uncom- 
promised nodes, where Q is a fixed upper bound for HORNET. 
Equivalently, we demonstrate that the adversary, with significantly 
less than 2^ computation, can only produce a requisite message 
with a negligible probability. In our proof, we choose Q = r+l. 

Suppose that an adversary can constructs an HORNET AHDR 
(F5'o,7o,/3o) that can succeed in traversing r + l honest nodes uq, 

■^See definitions by Camenisch and Lysyanskaya ffTl . 



n2, rir, without knowing secrets SVq, ■■■ , SVr- According to 
Algorithm!?] FSr, Pr-, and 7^ satisfy: 

= MAC{hMAc{PRP'\hpRp{SVr);FSr)[Q..c])\Pr) (24) 

For convenience, for i < j < r — 1, we introduce the following 
notations: 



4>{SV,FS) 


= PRp-'{hpRp{SV);FS) 


(25) 


p{SV,FS) 


= PRG{hpRG{<t>{SV,FS))) 


(26) 


Pi 


= p{SV„FS*) 


(27) 


Pf 


~ {Pi}[c(r-l-i)..c(r-l-i)+/jrs-l] 


(28) 


p1 


~ {Pi}[c(r-l-i)+lFs--c(r-i)-\\ 


(29) 


pf 


= {ft}[()..c(.+ l)-l]l|0^(^-'-^) 


(30) 


P13 


= {Pi\\jc..(] + \)c-\\ 


(31) 



where FS* are defined recursively as follows: 

FSl = FS,, (32) 
j-i 

FS* = FSi®@{pi}[c(^j+i_^y,,(^j+i_x)+ips-\] '^33) 

We observe that FS* is a function of {FSj | VO < j < i} and 

{SVj I VO < j < i - 1}. Accordingly, pf^, p] , and pf are all 
functions of {FSj | VO < j < i} and {SVj | VO < j < i - 1}. 

With a detailed inspection into Algorithm |4] we can express 
FSr, Pr, and 7^: 

r-l 

FSr = 0pf^ (34) 

i=0 

Ir = 0p7 (35) 

i=0 

r-l 

Pr = 0pf (36) 

i=0 

(37) 

With Equation (34] [35] [36] and [24] we can prove the following 
lemma: 

Lemma 1. With less than 2^ work, an adversary can only dis- 
tinguish MAC{hMAC {4'{SVr ,FSr)p c])'^ Pr) from a random or- 
acle with negligible probability. 

Proof. (Sketch) We will show that an adversary could not find two 
sets of 

{SVa,--- ,SVr,FSo--- ,FSr-i) + [SV^,,--- ,SV;,FSi-- ,F5,,_|) 

that leads to the same value of MAC{hMAc{'t>{SVr,FSr)[o..c])',Pr) 
with significant less than 2*^ work. 

Assume that the adversary, with much less than 2^ work, finds 
two sets, 

{SVo, ■■■,SVr,FSo---, FSr) + {SV!,, ■ • ■ , SVl,FS[, ■■■,FS',} 
that results in the same value of 

MAC{hMAcWSVr,FSrXQ..c]y,Pr) 

We will show the assumption leads to an contradiction. 

Because AIAC is a random oracle, the only way for an attacker 
to distinguish the target function from a random oracle with much 
less than 2^ work is to ensure 

^{SVr,FSr\o..c] = <^(SV;',FS;)[o..e] 

and Pr = P'r- Because PRP is a pseudo-random permutation and 
hppp is collision resistant, we have SVr = SV^. 

Note that the last c bits of Pr and P'^ are and j ^. j' 

respectively. Therefore, we have p^_i = Pr-i , i'- According 

to Equation [3T] because PRG is a pseudo-random generator, we 
have SVr-i = SVr-i and FS;_i = FS;_/. Hence, p^_i = 
P^_i,/,VO<j<r-l. 
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A careful calculation shows that the c bits before the last c bits 

in I3r and ^J. are Pr-2,r-2® Pr-l.r-2 and Pr-2,r-2 ® Pr-l.r-2 ■ 

Similarly, we have SVr-2 = SVr-2' and FS*_2 = FSl_^. 

Continuing the logic in the way above, we finally have SVi = 
SVl and FS* = FS*', VO < i < r - 1. However, given Equa- 
tion [H] 5"^^ = SVl, and FS^ = FS^', we have FS, = FS[, 
VO < i < r — 1. That says, 

{SVo,--- ,SVr,FSo--- ,FSr-i) = (SV^r-- ,SVl.,FS'o--- ,FS,,_i) 

. Therefore, we obtain a contradiction. □ 

We can substitute Equation[34l[35l and[36]into Equation|24l and 
rewrite the equation into: 

r-l 

= MAC{hMAcWSVr,FSr)p..c]y^l3r)®®p] (38) 

Because MAC is not used in pj, the right side of Equation|38]is a 
random oracle with respect to SVi and FSi, VO < i < r — 1. 

We can further simplify the notation by denoting pg as fo{SVo,FSo) 
and the right side of Eauationl38las 

fi{FSo,---,FSr-uSVo,---,SVr-i) 
. Both /o and f[ are random oracle with range {0,1}'^. As a result, 
by creating a AHDR traversing r+ I honest nodes, the adversary 
equivalently finds a solution to 

fo{SVo,FSo) = MFSo,--- ,FSr-l,SVo,--- ,SVr-l) 
which obviously can only be solved with negligible probability 
with significantly less than 2^^ work. That says, with much less 
than 2*^ work, the adversary can only generate a packet that tra- 
verse r + 1 hops with negligible probability. 

5.1.3 Wrap-resistance 

To prove the wrap-resistance property, we show that given a data 
packet (FS',7,/3,P), an adversary, with significant less than 2^ 
work, cannot generate a message {FS' ,y ,l3' ,P) so that process- 
ing {FS' ,y ,13' ,P) on an uncompromised node yields data packet 
{FS,'y,l3,P). 

To succeed, it is necessary thatiijZ 

P®{Pc..cr-i\\Ol = PiSV',FS') (39) 
Consider the last c bits of the left side of Equation[39l we have: 

P[cir-l]..cr-l] = PiSV ,FS')[c(r-\)..cr-\] (40) 

Because PRG, PRP, hpnQ, and hpup are all random oracles, 
an adversary could generate FS' and SV that satisfy Equation|40| 
only with negligible probability if the adversary performs much 
less than 2^ work. 

5.1.4 Security 

In order to demonstrate the security property, we need to prove 
that an adversary with controls over all nodes on a path except one 
node A'^, cannot distinguish among data packets entering TV. The 
adversary is able to select paths for the packets traversing A*' and 
payloads of the packets. The adversary can also observe packets en- 
tering and leaving node A'^ except for packets whose headers match 
the challenge packets. 

We construct the following game G. The adversary picks two 
paths (no,ni,--- ,ny_i) Q < u <r and {n'Q,n'-^,- ■ ■ ,n'^i_^) 0 < 
v' < r, where rii = n'^MO < i < j and rij = n'j = N. Note that 
the nodes after A'^ in both paths are not necessarily the same set 
of nodes, and the lengths of the paths can also be different. The 
adversary chooses the public/private key pairs and SVi(SVl) for 
all nodes except TV and can arbitrarily select payload M. 

The challenger picks randomly a bit b and proceeds in one of the 
following two ways: 

6 = 0: The challenger creates an AHDR (F5'o,7o, A)) through 
the HORNET setup phase using the path (no,ni,--- ,n^_i) and 
uses it to construct a data packet with onion encrypted payload TV/*^ 



from M. The challenger outputs {FSo,^o,l3o,M''), which could 
be sent to no- 

6=1: The challenger creates an AHDR (-FSojTOi/^o) using the 
alternative path (nj,, n'j , • • • , n'^_i) instead and outputs 
{FSo,^(),I3q,AI'^), which could be sent to u'q. 

Given the output {FS(),"fo,l3()), the adversary's goal is to deter- 
mine b. The adversary can also input any messages (_F5", 7', /?', Af^') 
to the honest node TV and observes the output messages as long as 
{FS',j',P')^{FSj,-fj,Pj)B 

We define the adversary's advantage as the difference between j 
and the probability that the adversary succeeds. We will show that 
the adversary's advantage is negligible. That says, the adversary 
has no better chance to determine 6 than random guessing. 

Proof. (Sketch) We adopt the method of hybrid games. First, we 
construct a modified game Gi with exactly the same definition, ex- 
cept that we require j = 0. An adversary who can win G can thus 
immediately win G\. On the other hand, because the adversary 
controls nodes (ng, • • • , nj^i ) ((rig, ■ ■ • , )) and can thus emu- 
late their processing, the adversary can also win game G if he/she 
can win game G\ . Therefore, the adversary can win game G if and 
only if the adversary can win game Gi . 

We create a second game G2, which is the same as G\ except 
that FSo, Pi), and 70 are all randomly generated from their corre- 
sponding domains. If the adversary can distinguish G2 from Gi, 
we have: 

1 . The adversary can distinguish 

FSo = PRP{hpIip{SV^))■ms^)) 
from randomness. Then it must be that the adversary is able 
to tell the output of a pseudo-random permutation with a ran- 
dom key {hppp{SVo)) from random bits. The probability 
of success for the adversary is negligible. 

2. The adversary can distinguish 

A) = PRG{hp„G{SVQ)) e {FS, I |7i I \Pi } 
from randomness. Then it must be the adversary is able to 
distinguish the output of a secure pseudo-random number 
generator with a random key {hpiiQ{SVQ)) from random- 
ness. The probability that the adversary succeeds is negligi- 
ble. 

3. The adversary can distinguish 

70 = MAG(ftMAc(^Vb); A,) 
from randomness. Then it must be the adversary is able to 
distinguish the output of MAC with a random key Hmac {SVq) 
from randomness. Under our random oracle assumption for 
MAG, the probability of success is negligible. 
Therefore, the adversary cannot distinguish G2 from Gi . 

At last, because in G2, {FSq, 'JqjPq) are all random, the adver- 
sary's advantage is 0. Moreover, in our chain of game G ^ Gi — >■ 
G2, the adversary can only distinguish a game from its previous 
game with negligible probability. As a result, the adversary's ad- 
vantage in game G is negligible. □ 

5.2 Passive De-anonymization 

Session linkage. Each session is established independently from 
every other session, based on fresh, randomly generated keys. Ses- 
sions are in particular not related to any long term secret or identi- 
fier of the host that creates them. Thus, two sessions from the same 
host are unlinkable, i.e., they are cryptographically indistinguish- 
able from sessions of two different hosts. 

Forward/backward flow correlation. The forward and backward 
headers are derived from distinct cryptographic keys and therefore 

'^We follow the definition of security property in 1171 and only care 
about header uniqueness. 
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cannot be linked. Only the destination is able to correlate forward 
and backward traffic, and could exploit this to discover the round- 
trip time (RTT) between the source and itself, which is common to 
all low-latency anonymity systems. Sources, willing to thwart such 
RTT-based attacks from malicious destinations, could introduce a 
random response delay for additional protection. 
Packet correlation. HORNET obfuscates packets at each hop to 
prevent an adversary observing two points on a path from linking 
packets between those two points using packets' bit-patterns. Be- 
sides the use of onion encryption, we also enforce this obfusca- 
tion by padding header and payload to a fixed length, thwarting 
packet-size-based correlation|f| While this does not prevent the ad- 
versary from discovering that the same flow is passing his observa- 
tion points using traffic analysis, it makes this process non-trivial, 
and allows upper layer protocols to take additional measures to 
hide traffic patterns. The hop-by-hop encryption of the payload 
also hides the contents of the communication in transit, protect- 
ing against information leaked by upper layer protocols that can be 
used to correlate packets. 

Flow-dynamics-based end-to-end correlation. In general it is 
difficult even for high latency mix networks to resist such powerful 
adversaries ||34J . Low-latency anonymity systems are particularly 
prone to these types of attacks 1 43] 1301 . HORNET cannot protect 
against them, but as mentioned above, the use of packet obfuscation 
makes these attacks more expensive and allows for potential addi- 
tional measures to be taken (e.g., padding), either by upper layer 
protocols or by extensions of HORNET. Mass surveillance based 
on end-to-end confirmation attacks requires an adversary to mon- 
itor a large fraction of the nodes of the network and to store and 
process all intercepted traffic, so it falls outside our attacker model. 

5.3 Active De-anonymization 

Session state modification. The state of each node is included in 
an encrypted FS. During the session setup, the FSes are inserted 
into the FS payload, which allows the source to check the integrity 
of these FSes during the setup phase. When the FSes are carried 
in the AHDR, they are integrity-protected as well thanks to per-hop 
MACs computed by the source. This second case needs clarifi- 
cation, however, since it involves a particular construction. Each 
MAC protecting an FS is computed using a key contained in that 
FS. This construction is secure because every FS is encrypted us- 
ing a PRP keyed with a secret value known only to the node that 
created the FS: if the FS is modified, the authentication key that 
the node obtains after decryption is a new pseudo-random key that 
the adversary cannot control. Thus, the probability of the adversary 
being able to forge a valid MAC is still negligible. 
Path modification. Both HORNET data structures that hold paths, 
i.e., the FS payloads in the setup phase and the AHDRs, use chained 
per-hop MACs to protect path integrity and thwart attacks like in- 
serting new nodes, changing the order of nodes, and splicing two 
paths. The source can check such chained per-hop MACs to detect 
the modifications in the FS payload before using the modified FS 
payload to construct AHDRs, and similarly intermediate nodes can 
detect modifications to AHDRs and drop the altered packets. 
Replay attaclts. Replaying packets can facilitate some types of 
confirmation attacks. For example, an adversary can replay pack- 
ets with a pre-selected pattern, and have a colluding node iden- 
tify those packets downstream. HORNET offers replay protection 
through session expiration. Replayed packets whose sessions have 
expired are immediately dropped. Replay of packets whose ses- 



^ An alternative for a more optimized bandwidth usage would be to 
allow two or three different payload sizes, at a cost of decreased 
anonymity. 



sions are not yet expired is possible, but the risk of misbehaving 
nodes being detectecQ might deter an adversary from using replays 
to conduct mass surveillance. 

Payload tagging or tampering. HORNET does not use per-hop 
MACs on the payload of data packets for efficiency and because 
the destination would not be able to compute such MACs. The 
lack of integrity protection allows an adversary to tag payloads. 
Admittedly, by using tagging in conjunction with replay attacks, 
the adversary is able to improve the effectiveness of confirmation 
attacks. However, the end-to-end MACs protect the integrity of the 
data, making such attacks (at a large scale) detectable. 

5.4 Denial-of-Service (DoS) Resilience 

Computational DoS. The use of asymmetric cryptography in the 
setup phase makes HORNET vulnerable to computational DoS at- 
tacks, where adversaries can attempt to deplete a victim node's 
computation capability by initiating a large number of sessions through 
this node. To mitigate this attack, HORNET nodes should rate-limit 
the number of session setup packets that are processed per neigh- 
bor. 

State-based DoS. HORNET is not vulnerable to attacks where ad- 
versaries maintain a large number of active sessions through a vic- 
tim node. One of HORNET'S key features is that all state is carried 
within packets, thus no per-session memory is required on nodes or 
rendezvous points. 

5.5 Topology-based Analysis 

Unlike onion routing protocols that use global re-routing through 
overlay networks (e.g.. Tor 1 23 1 and I2P 1 47 1), HORNET uses short 
paths created by the underlying network architecture to reduce la- 
tency, and is therefore bound by the network's physical intercon- 
nection and ISP relationships. This is an unavoidable constraint for 
onion routing protocols built into the network layer |29, 42 1. Thus, 
knowledge of the network topology enables an adversary to reduce 
the number of possible sources (and destinations) of a flow by only 
looking at the previous (and next) hop of that flow. For example, 
in Figure |3(a)[ assume that ASO is controlled by a passive adver- 
sary. The topology indicates that any packet received from ASl 
must have originated from a source located at one of {ASl, AS2, 
AS3, AS4, AS5). 

We evaluate the information leakage due to the above topology 
constraints in the scenario where a single AS is compromised. We 
derive AS-level paths from iPlane trace-route data [tQ, and use 
AS-level topology data from CAIDA |33|. For each AS on each 
path we assume that the AS is compromised and receives packets 
from a victim end host through that path. We compute the end 
host's anonymity set size that the adversary learns according to the 
topology. Similar to Hsiao et al. Ii29j , we use the number of IPv4 
addresses to estimate the size of the anonymity set of end hosts. 
Figure [3(b)] plots the CDF of the anonymity set size for different 
distances (in number of AS hops) between the adversary and the 
victim end host. For adversarial ASes that are 4 hops away, the 
anonymity set size is larger than 2-" in 90% of the cases. Note that 
the maximum anonymity set size is 2-'^ in our analysis, because we 
consider only IPv4 addresses. 

Implications of path knowledge. Knowledge about the path, in- 
cluding the total length of the path and an adversarial node's po- 
sition on the path, significantly downgrades the anonymity of end 
hosts. Considering again Figure [3(a)] if the adversary controlling 
ASO sees a packet incoming from AS 1 and knows that it is 4 hops 

^Volunteers and organizations might monitor the network, and hon- 
est ASes might control their own nodes as part of an IDS. 
^Traceroute data was generated on October 12, 2014 
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Figure 3: a) An example AS-level topology with an adversarial AS (ASO); b) CDF of anonymity-set size when a position-agnostic 
AS on path is adversarial. "Hops" indicates the number of ASes between the adversarial AS and the victim end host, c) CDF of 
anonymity-set size when an adversarial AS knows its own position on the path. 



away from the source host, he learns that the source host is in AS4. 
Compared with the previous case, we see that the anonymity set 
size is strongly reduced. 

We quantify additional information leakage in the same setting 
as the previous evaluation. Figure [3(c)l represents the CDFs of the 
anonymity set sizes of end hosts according to the distance to the 
compromised AS. The anonymity set sizes are below 2^^ in 90% 
of the cases when the adversarial ASes are 4 hops away, with an 
average size average size decreases to 2^^ for the cases 

where the adversarial ASes are 7 hops away from the target hosts. 

Previous path-based anonymity systems designed for the net- 
work layer either fail to hide knowledge about the path |42 1 or only 
partially obscure the information |29|. In comparison, HORNET 
protects both the path length and the position of each node on the 
path, which significantly increases the anonymity-set size of the 
end hosts, as our analysis in this section showed. 

6. EVALUATION 

We implemented the HORNET router logic in an Intel software 
router using the Data Plane Development Kit (DPDK) |4|. To our 
knowledge, no other anonymity protocols have been implemented 
in a router SDK. We also implemented the HORNET client in 
Python. Furthermore, we assembled a custom crypto library based 
on the Intel AESNI crypto library |6|, the curve25519-donna li- 
brary 1 3 1, and the PolarSSL libraries |9|. For comparison, we im- 
plemented the data forwarding logic from LAP, Dovetail, and L3 
Toi0 and Sphinx using DPDK and our crypto library. We use IP 
forwarding in DPDK as our performance baseline. 

Our testbed contains an Intel software router connected to a Spirent 
TestCenter packet generator and analyzer 111]. The software router 
runs DPDK 1.7.1 and is equipped with an Intel Xeon E5-2680 
processor (2.70 GHz, 2 sockets, 16 logical cores/socket), 64 GB 
DRAM, and 3 Intel 82599ES 40 Gb/s network cards (each with 4 
10 Gb/s ports). We configured DPDK to use 2 receiving queues for 
each port with 1 adjacent logical core per queue. 

6.1 Data Forwarding Performance 

Forwarding latency. We measure the CPU cycles consumed to 
forward a data packet in all schemes. Figure [5(a)] shows the aver- 
age latency (with error bars) to process and forward a single data 
packet in all schemes when payload sizes vary. We observe that 
data forwarding in Sphinx is 3 orders of magnitude slower than that 

^For fair comparison, we only implement payload encryp- 
tion/decryption. We do not implemented SSL/TLS or L4 transport 
control logic. 



Scheme 


Header Length 


Sample Length (Bytes) 


LAP 


12 + 2s-r 


236 


Dovetail 


12 + s-r 


124 


Sphinx 


32+(2r + 2)s 


296 


Tor 


3+11-r 


80 


HORNET 


S + 3r-s 


344 



Table 1: Comparison between the length of different packet 
header formats in bytes, s is the length of symmetric elements 
and r is the maximum AS path length. For the sample length, 
we select s = 16 Bytes and r = 7. Analysis of iPlane paths shows 
that more than 99% of all paths have less than 7 AS hops. 

of HORNET, L3 Tor, LAP, and Dovetail because Sphinx requires 
per-packet asymmetric crypto operations. We further observe that 
HORNET, even with onion encryption/decryption over the entire 
payload and extensive header manipulation, is only 5% slower than 
LAP and Dovetail for small payload (64 bytes). For large payloads 
(1200 bytefl), HORNET is 71% slower (about 400 nanoseconds 
slower per packet when using a single core) than LAP and Dove- 
tail. However, the additional processing overhead enables stronger 
security guarantees. 

Header overhead. As a result of carrying anonymous session state 
(specifically cryptographic keys) within packet headers, HORNET 
headers are larger than Sphinx, L3 Tor, LAP, and Dovetail headers 
(see Table [TJ. While larger headers reduce net throughput (i.e., 
goodput), this tradeoff appears acceptable: compared to L3 Tor, 
no state is required at relay nodes, enabling scalability; compared 
to Sphinx, data processing speed is higher; compared to LAP and 
Dovetail, HORNET provides stronger security properties. 

Throughput. To compare the throughput of data forwarding, we 
measure the throughput of all schemes on a single CPU core on a 
10 Gb/s link with different payload sizes. The result is shown in 
Figure |6T| We observe that all schemes except Sphinx can satu- 
rate the lOGb/s link when the payload size is larger than 512 Bytes. 
When payload size is smaller than 256 Bytes, HORNET'S through- 
put is 20% - 30% smaller than LAP and Dovetail, whose through- 
put, in turn are 25% smaller than IP forwarding. Note, Tor's small 
throughput at small payload sizes is mainly a reflection of its small 
per-hop header size, as later proved in Figure [5(b)l In comparison, 
Sphinx can only achieve 0.05Gb at its maximum when the packet 

''Because LAP, Dovetail, and HORNET all have large packet head- 
ers of 300-1- bytes, we limit the largest payload in our experiments 
to be 1200 bytes. 
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size is 1500 Bytes because of its expensive data forwarding. 
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Figure 4: Data forwarding throughput on 10 Gb/s linli 

Goodput. We further compare all the schemes by goodput, which 
excludes the header overhead from total throughput. Goodput is a 
comprehensive metric to evaluate both the packet processing speed 
and protocol overhead. For example, a scheme where headers take 
up a large proportion of packets yields only low goodput. On the 
other hand, a scheme with low processing speed also results in poor 
goodput. 

Figure [5(b)] and Figure [5(c)] demonstrate the goodput of all schemes 
on a lOGb/s link when varying the number of hops, with 40-byte 
and 1024-byte payloads, respectively. We observe that Sphinx's 
goodput is the lowest in both cases because of its large packet head- 
ers and slow asymmetric-crypto-based packet processing. 

When the payload size is small, the goodput of all protocols 
remains stable. This is due to the fact that no scheme can sat- 
urate the link, and accordingly the goodput differences between 
the three schemes mainly reflect the different processing latencies 
among them. Consequently, L3 Tor's and HORNET'S goodput is 
32% less than that of LAP and Dovetail. On the other hand, when 
the payload size is large, all schemes except Sphinx can saturate 
the lOGb/s link. HORNET can reach 93% of LAP and Dovetail's 
goodput while providing stronger security guarantees. 

6.2 Max Throughput on a Single Router 

To investigate how our implementation scales with respect to the 
number of CPU cores, we use all 12 ports on the software router, 
generating HORNET data packets at 10 Gb/s on each port. Each 
packet contains a 7 AS-hop header and a payload of 512 bytes, and 
is distributed uniformly among the working ports. We monitor the 
aggregate throughput on the software router. 

The maximal aggregate throughput of HORNET forwarding in 
our software router is 93.5 Gb/s, which is comparable to today's 
switching capacity of a commercial edge router |2|. When the 
number of cores is less than 5, our HORNET implementation can 
achieve full line rate (i.e., 10 Gb/s per port). As the number of cores 
increases to 5 and above, each additional port, with the two logical 
cores binded to the port, adds an extra 6.8Gb/s. 

6.3 Session-Setup Performance 

We evaluate the latency introduced by processing setup packets 
on each border router. Similar to measuring the latency of data for- 
warding, we also instrument the code to measure CPU cycles con- 
sumed to process packets in the session-setup phase. Table[2]lists 



the average per-node latency for processing the two setup packets 
in hornet's session-setup phase. Due to a Diffie-Hellman key 
exchange, processing the two setup packets in the session-setup 
phase increases processing latency (by about 240/is) compared to 
data packet processing. However, HORNET must only incur in this 
latency once per session. 



Packet 


Latency (K cycles) 


Latency (/is) 


PO 


661.95 ±30.35 


245.17 ±11.24 


P© 


655.85 ± 34.03 


242.91 ± 12.60 



Table 2: Per-node latency to process session-setup packets with 
standard errors. 



6.4 Network Evaluation 

Distribution of AS-level path length.. The bandwidth overhead of 
a HORNET packet depends on the number of ASes traversed by the 
packet. Figure[6]demonstrates the CDF of AS-level path lengths of 
the paths extracted from our data source. We observe that 99% of 
the paths have a path length smaller than 7, and the mean AS-level 
path length is 4.2. Thus, to achieve 128 bits of security, 48 bytes 
per AS hop are required, leading to an average overhead of 201.6 
bytes. 




4 6 8 10 

AS-level path length 

Figure 6: CDF of AS-level path length. 

Non-scalability of a stateful design. We evaluate the memory 
capacity needed to maintain state required by a stateful design to 
support Internet-scale anonymous communication. We consider 
the design of Tor, one of the most popular onion routing systems 
today 1 23 1, and assume that each Tor node (onion router or OR) 
would correspond to an autonomous system (AS), as proposed by 
Liu et al. |:32|. Analyzing the CAIDA Internet Traces 1 1 1, we found 
that a 10 GbE backbone link handles about IM new flows every 
minute under normal operating conditions. Since the largest inter- 
AS links today have up to ten times that capacity (100 Gbps|3, this 
means that at the core of the network there are edge routers of ASes 
that handle about lOM new flows per minute. 

If we assume that half of these flows would use a Tor circuit, 
because of the default lifetime of circuits of 10 minutes^ we ob- 
tain that ORs on such edge routers would need to store state for 

"'E.g., see www. seattleix . net /participants . htm. 
" We actually measured the number of flows taking this lifetime into 
account, in particular we expired flows only if no packets where 
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Figure 5: a) Per-node data forwarding latency on a 10 Gbps link; b)Data forwarding goodput on a 10 Gbps link for small packets (40 
Bytes payload); c) Data forwarding goodput large packets (1024 Bytes payload). For a), lower is better; for others, higher is better. 



approximatively 50M circuits at all times. Since Tor stores at least 
376 bytes per circuit, tliis translates to almost 20 GB of memory. 
This might still be acceptable for high-end devices, but there are 
a number of additional factors that make keeping state unfeasible, 
even for ASes handling less traffic: 

• The growing number of user on the Internet and the increas- 
ing number of devices per user result in an increasing number 
of traffic flows; 

• The state for each circuit would actually be larger, as for ac- 
tive circuits the ORs need to store the packets being trans- 
mitted until they are acknowledged by the next hop; 

• A DDoS attack could force an OR to store much more state 
by opening a large number of new circuits through that OR. 

7. DISCUSSION 

7.1 Retrieving Paths Anonymously in FIAs 

HORNET assumes that the source host can obtain a forward path 
and a backward path to an intended destination host anonymously 
in FIAs. We briefly discuss how a source host using HORNET can 
retrieve such two paths in NIRA, SCION and Pathlet. 

NIRA and SCION hosts rely on path servers to retrieve paths. In 
both architectures, each destination node registers its path to/from 
the network "core" on a centralized path server. A source only 
needs to anonymously fetch the information registered by the desti- 
nation to form forward and backward paths, which could be done in 
two ways. As a first method, the source can obtain the paths to/from 
the path servers from resolver configuration or local services simi- 
lar to DHCP and establish an anonymous HORNET session to the 
servers. Once the HORNET session is created, the source can pro- 
ceed to anonymously request a path to the destination. Alterna- 
tively, the source can leverage a PIR scheme to retrieve the path 
anonymously from the path server. 

In Pathlet routing, the situation is different because the routing 
information is disseminated through a path vector protocol. The 
source can keep a local database of pathlets and simply query the 
database locally for the pathlets to a certain destination. 

7.2 Composability with other protocols 

HORNET operates at the network layer. As such, upper-layer 
anonymity protocols may be used in conjunction with HORNET to 
provide stronger anonymity guarantees. For example, to help mit- 
igate concerns of topology-based attacks (as seen in Section l53t . 

seen on them for over 10 minutes. Also note that in our setting it 
would not be possible to have multiple streams per circuit, unless 
the destinations those streams are in the same AS. 



a single hop proxy or virtual private network (VPN) could be used 
to increase the size of the anonymity sets of end hosts. Similar 
solutions could also protect against upper-layer de-anonymization 
attacks, in particular fingerprinting attacks on the transport proto- 
col |44|. 

At lower layers, HORNET is also compatible with link-layer 
protection such as link-level encryption. The role of link-level en- 
cryption in HORNET is comparable to SSL/TLS in Tor. Link en- 
cryption prevents an adversary eavesdropping on a link from being 
able to distinguish individual sessions from each other, therefore 
making confirmation attacks much harder for this type of adver- 
sary. 

7.3 Targeted confirmation attacks 

When an adversary controls more than one node on a path, it 
can launch confirmation attacks by leveraging flow-dynamics anal- 
ysis, timing, and packet tagging, all of which can be further assisted 
by replay attacks. HORNET, like other low-latency onion routing 
schemes 1231 . cannot prevent such confirmation attacks targeting 
individual users. However, HORNET raises the bar of deploying 
such attacks for secretive mass surveillance: the adversary must 
be capable of controlling a significant percentage of ISPs often re- 
siding in multiple geopolitical boundaries, not to mention keeping 
such massive activity confidential. 

8. RELATED WORK 

Anonymity system using overlays. The study of anonymous com- 
munication began with Chaum's proposal for mix relays |19| . A 
number of message-based mix systems have been proposed and 
deployed since |28, 36, 20 21 1. These systems can withstand an 
active adversary and a large fraction of compromised relays, but 
rely on expensive asymmetric primitives, and message batching 
and mixing. Thus, they suffer from large computational overhead 
and high latency. 

Onion routing systems I41II23I were proposed to efficiently sup- 
port interactive web traffic. Onion routing systems are vulnerable 
against end-to-end correlation attacks |31 1, and may fail to provide 
unlinkability when two routers on the path are compromised |27| 
\3U\. While these systems are generally intended as overlays, some 
proposals 1141 1151 are closer to the network layer in that they use 
UDP (instead of TCP |23|) between pairs of onion routers. HOR- 
NET distinguishes itself from all of these systems in two ways: it 
does not store per-connection state on the nodes, and it requires 
only a single round trip to establish an anonymous path. 

Anonymity systems in FIAs. Hsiao et al. (29l explored the de- 
sign space of efficient anonymous systems with a relaxed adversary 
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model. In their scheme, LAP, the adversary can compromise only 
a single node, and the first hop must always be honest. Sankey 
and Wright proposed Dovetail L42il (based on Pathlets |26| and 
SCION |48|) which has the same attacker model as LAP, except 
it allows the first hop to be compromised. Compared to HORNET 
and to onion routing, LAP and Dovetail do not offer protection to 
the payload, and they allow nodes to learn their position on the 
path. 

The research community has also explored applying onion rout- 
ing to FIAs. Liu et al. |32 | proposed Tor instead of IP as an FIA 
that regards anonymity as the principal requirement for the network 
architecture. However, details on how to scale Tor's current design 
(requiring per-circuit state) to Internet scale were not addressed. 

DiBenedetto et al. 1 22 1 proposed ANDaNA, to enable onion rout- 
ing in Named Data Networking (NDN). NDN focuses on content 
delivery and thus inherently different from the FIAs we considered. 

9. CONCLUSION 

In this paper, we address the question of "what minimal mech- 
anism can we use to frustrate pervasive surveillance |24|?" and 
study the design of a high-speed anonymity system supported by 
the network architecture. We propose HORNET, a scalable and 
high-speed onion routing scheme for future Internet architectures. 
HORNET nodes can process anonymous traffic at over 93 Gb/s 
and require no per-flow state, paving the path for Internet-scale 
anonymity. Our experiments show that small trade-offs in packet 
header size greatly benefit security, while retaining high perfor- 
mance. 
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